If you like KeePass and would like to help me in some way:
Donate
This is maybe the best way of helping me, if you don't have that much time or experience in application development. This is
the recommended way of helping me for standard users.
Make a translation
If you have some free time, you could make a translation of KeePass (of course only if you're language isn't offered already)!
Test new releases and submit bugfixes
KeePass is under constant development, new features get implemented, bugs get fixed. If you have some free time, you could just
test the new releases thoroughly and if you're a programmer, look through the sources to find bugs and maybe even submit fixes.
Spread the word
KeePass isn't that widely-known yet. If you like KeePass, tell all your friends how great KeePass is, publish articles
about it, press it on CDs/DVDs, sell it with your USB sticks, submit it to software archives, talk in forums about it, etc.!
My options aren't saved! Why?
When saving the options, KeePass does the following:
Try to save the options to the global KeePass.ini file in the KeePass program directory.
If this fails (for example if the program directory is protected), write the options to a KeePass.ini file in the users directory (subdirectory 'KeePass' in application data).
When loading, KeePass performs the following:
Try to find the key (the option) in the global KeePass.ini file.
If this fails (file inaccessible or key doesn't exist), try loading it from the KeePass.ini file in the users directory (subdirectory 'KeePass' in application data).
Now, if you use the KeePass installer and install it with admin rights, the program directory will be write-protected when working
as a normal user. That means that KeePass saves your options into your users directory, but loads them from the global KeePass.ini.
If you want KeePass to use just the users directory, logon to Windows with admin rights and delete the global KeePass.ini in the
program directory. This forces KeePass to use the KeePass.ini in the users directory for both reading and writing when logging
on as normal Windows user (without admin rights).
A note to network administrators: all settings in the global KeePass.ini file override the settings of the users. That means that
you can selectively force some options, but leave other options to the users. For this, open the global KeePass.ini file on the
network drive and have a look at it. Delete all entries that you want to leave up to the user (don't just set it to nothing,
delete the line completely!). The options you set in the global KeePass.ini are forced for all users, all other options
are configurable by the users (they are written to the KeePass.ini in the users directory). Make sure you write-protect
the global KeePass.ini on the network drive so nobody can overwrite it.
Rename columns / other "card types" feature requests
Many feature requests like these have been posted over and over again: rename the columns, add more URL fields,
add an entry-type field (let the user define whether that entry is a login account, credit card, etc.), hide some
dialog elements for some special entry-type,
support different "card types" (you could choose "credit card" as entry-type and KeePass would show
fields needed for credit card information), etc.
KeePass has been designed from ground up to have the fixed fields you see in the add-entry dialog. All parts of KeePass,
starting from the core password manager, all the dialogs, up to the main GUI code, are based on this. Supporting
different card types would require a total rewrite of almost all the code. Really almost everything would
have to be changed, the tree/listview layout system wouldn't work any more, the database format would have to be
rewritten from scratch, many of the dialogs would have to be redesigned totally. Short: it's impossible. Creating
a completely new project would be far less work than implementing this into KeePass.
Even if I would provide the ability to rename the columns/fields, the structure would remain. For example, the URL field
would continue to be a clickable URL field, though you would have declared it as "PIN" field. This would
confuse more users than help some, therefore I won't implement any renaming ability.
E-mail address field feature request
Especially one feature request is made very often: add an e-mail field. For e-mail accounts for example you would need
such a field. I won't add an e-mail field, you can use the username field for this. There are mostly two "types"
of e-mail accounts: either enter a username and a password (standard e-mail servers) or enter your e-mail address and
a password (web-based e-mail services) to login. The first one isn't a problem anyway and for the second one you can just store
your e-mail address in the username field. Even if your provider requires 3 fields (username and e-mail address and
password) to login, you can for example just modify the auto-type sequence (so practically store your e-mail
address in the auto-type sequence) or store the additional data in the title, URL or notes field.
The end-user must be flexible enough to use the username or URL field for e-mail addresses, the password fields for credit
card numbers, etc. The notes field accepts the rest, i.e. everything that doesn't fit into the title / user-name / URL
/ password field scheme.
Will there be KeePass versions for other OSs than Windows?
The desktop KeePass application has been developed from start on to work on Windows operating systems. It uses the Microsoft Foundation
Classes (MFC) and several other platform-dependent stuff that makes porting relatively hard.
Anyway, the KeePass core (i.e. the password management code, simply everything except the graphical user interface [GUI]) is
platform-independent and therefor "ports" are theoretically possible, although you cannot really speak of a port here,
since the whole user interface needs to be rewritten.
Also, KeePass is written in C++. No chance to convert it to Java to make it platform-independent. If you would like a KeePass
written in Java, have fun rewriting it completely from scratch. Although C++ and Java are relatively similar, converting the
existing C++ code to Java involves much work, most probably more work than just writing a completely new password manager in Java.
But people can make KeePass "ports", as one can easily see: KeePass for PocketPC.
I assume that, when rewriting the GUI code, you can "port" KeePass to almost any platform, since the core password
manager code is totally platform-independent.
Now before you ask when the Linux/PalmOS/etc. versions are ready: I don't know. I myself just don't have the time to develop
these versions. Keep in mind that I'm developing KeePass in my free time and, apart from donations, don't get anything
for it. I will
happily develop KeePass for Windows, also in the future yes, but I don't have the time to develop a Linux version
for example. I also never
programmed any single PalmOS program, I don't even own a PalmOS.
KeePass is Open-Source. If you have the time to develop KeePass-compatible applications (as said, it cannot be really "ported"),
feel free to contact me and I will happily support you as good as I can.
Secure Edit Controls are special password edit controls that are resistant to window spies and memory dumpers.
There are many tools that read out the entered passwords of standard Windows password edit controls. These standard
edit controls aren't secure: other applications can easily get the entered texts, even though Windows shows the nice
password asterisks/dots. Secure edit controls are resistant to this. None of the window spies are able to read
out the contents of a Secure Edit Control.
Additionally, Secure Edit Controls scramble the entered password in a way that it cannot even be found in the
process memory of the application. If Windows caches the whole application to disk while entering the password,
this wouldn't reveal the entered text anyway! The standard edit controls provided by Windows react completely different:
the password would be easily readable as plain-text.
KeePass was the first application offering this level of security. Since the source code for Secure Edit Controls
is open-source, most probably many other password managers will adopt and integrate them soon, too.
See the additional reading link [1] below for a detailed article on Secure Edit Controls (how they work, their limitations, etc.).